This document lists some of OpenDoc's "stickier" known problems. This is not a comprehensive list of OpenDoc bugs. Instead, we have listed the bugs that a user or developer is most likely to encounter when working with parts. For developers, if after debugging a problem you find that the bug is actually in OpenDoc, you might check this document first. Sometimes the engineers have included work-around information with the bug report. If you (a user or developer) encounter a bug that is not included in this list, please use the bug report form located in the same folder as this document to report the bug.
OpenDoc General
•OpenDoc Core and OpenDoc Shell both define the same "Kind" menu. OpenDoc Core and OpenDoc Storage both define the same
"Editor" menu.
•There are several places in OpenDoc code where we are not checking the result from GetStorageUnit(). Every time GetStorageUnit() is called on a frame, the result must be checked for nil before use to be completely safe. In general, this function can return nil when the frame is not persistent. Lack of checking for nil is causing crashes. The typical reason for getting a frame's storage unit is to get the session, and there is a workaround recipe for doing this for non-persistent frames.
OpenDoc Clipboard
•If the Macintosh scrap does not contain an OpenDoc clipboard, the current implementation of ODClipboard::ImportContent requires that the scrap is loaded into memory. This prevents incorporating content if the scrap is too large to be loaded into memory. It also means that the scrap cannot be unloaded to disk if there isn't room for both it and the OpenDoc clipboard in memory.
OpenDoc Core
•If the user opens an Info dialog from within a Viewer (not Editor) or from a read-only document, the "modifiable" items should be dimmed or unavailable, because the user cannot change anything. They, however, are available. Nothing actually happens if you make changes in the dialog and click ok. Reopening the dialog shows everything set back to the original settings.
•We don't warn the user at all when they have entered more text than will be considered valid. For example, the Document/Part Info comments boxes will let the user enter whatever they want, and we silently truncate it to a max of 255 roman chars (on roman systems its 255).
Example: Document Comments field.
•If a field is read-only, we allow the user to enter in data, then completely and silently ignore her/him.
Examples: Document/Part Name field and Document
Comments field of readonly drafts.
•We occasionally see "bogus" data in the Part Info dialog (if you drop an "unrecognized" data type into a container).
•A document is not saved as a stationary pad (when selected) if you are saving to a floppy, external disk or to the OpenDoc stationary folder.
•Choosing Part Info always dirties document even if cancel is chosen or no changes are made.
•In an OpenDoc document, choose Document Info from the Document menu. Click on the Size… button. The Memory Requirements dialog appears on top of the Document Info dialog. Note that in the Document Info dialog, only the Cancel and OK buttons are disabled; the Size… button and the popups appear enabled.
•The Part Info dialog shows bogus Category, Kind, and Editor items if editor is bad.
•Users may notice that the editor popups in the Part Info and Part Translation dialogs are different, and could be confused by this. Suppose that two editors, A & B, support content kind K. The Part Info dialog displays them in the order determined by GetAllEditorsForKind. However, the Part Translation dialog always displays the system preferred editor first. This can cause the
ordering of A & B to be different in the two dialogs.
• The PartInfo dialog shows empty Editor popup menu if part bound to NoPart editor.
•The comments for the root part are copied to the desktop DB where they appear in the Finder’s Get Info dialog. This does not happen on floppies because there is no API for doing so. Files on floppy will have either no comments or the comments present when they were copied to the floppy in their Get Info dialog.
•The implementation of the utility function GetThisKindFromList in InfoUtil.cpp does not return kODNULL if the argument index is zero. Instead, it returns the first type in the list.
OpenDoc Drag & Drop
•Parts can't be dragged to a GX printer icon.
•Dragging a large number of files over an OD doc takes a loooong time.
•OpenDoc has bogus category when self-embedding. Steps to reproduce:
1. Open a new document from some sort of container stationery.
2. Drag the Finder icon of the new document that was created into the OpenDoc document.
3. The embedded part will bind to NoPart, but it's category will be named ^0 copy
It should have a real category name.
•When a part, which is selected, but not activated, receives a drop which causes it to change the size, e.g. the width, the selection handles (knobs) aren't redrawn properly.
•When starting a drag within an activated part, and moving the mouse around in the activated part, the activated part receives no
DragEnter/DragWithin/DragLeave events, the containing part receives this events.
•If you drag a part to the Finder and there is already a file with that name, the user will get a warning saying there is already a file with that name. The user may choose to cancel the copy/move operation, or replace the file. The user should have the option to complete the move by renaming the document s/he is attempting to place. The workaround is to cancel the copy/move, choose part info, rename the part, and try again.
It may not be desirable for the user to permanently change the name of the part (for scripting purposes?), nor may it be possible (in a readonly draft). Note: If the draft is read only, and it is not possible to change the name of the part, the workaround is to change the name of the original file in the Finder. Failing that, moving the original file in the finder elsewhere. Failing that, the operation simply cannot be completed without using an interim place in the finder to copy and rename the part before moving it into its final folder.
•The process quits after save dialog in low memory. The problem is in the Drag&Drop Code. It appears the code is trying to create an in memory container for importing the file dragged in. Bento tries to allocate 48k in the app heap, but there is only 46k left. This causes the low mem dialog to appear. The dialog subsequently quits the process (after saving) which is REALLY NOT necessary because OpenDoc is really not in trouble; temp mem has tons of memory free. The only "problem" is Bento's
failed allocation.
•OpenDoc doesn't call DragBegin after calling DragLeave when it goes back to tracking over the same part. Offending method: ODDragAndDropInWindow (in DragDrp.cpp in Storage).
OpenDoc Dynamic Binding
•Changes to editor NMAP not noticed if editor is aliased from Editors folder. Example:
1) In the Editors folder in the System folder, create an alias to an OpenDoc Editor library located elsewhere.
2) Change the NMAP resource of the Editor, like removing a platform type currently supported.
3) Open stationery of the editor, put some content on the OpenDoc clipboard of the kind removed from the NMAP, and choose Paste As. Notice that the kind is still appears enabled in the Kind popup. If the editor resides in the Editors folder, the updated NMAP
is used, and the kind no longer appears enabled.
While we may recommend and expect editors to be installed in the Editors folder, users may put aliases there instead. If they do, they may encounter problems if they update or remove the actual editor file. The workaround, of course, is to not place aliases in the Editors folder.
•When a HelpFile 'nmap' resource is being loaded, the existence of the help file should be verified before adding an entry to the HelpFile name space. The work around for this is for the part Editor to verify the existence of the help once it has retrieved the help file fsspec from the HelpFile name space. If the file does not exist, continue reading 'nmap's. DO NOT throw or report a problem since installing the file later on will cause 'nmap's to be reloaded.
•Binding caches removeable volumes with no editors so you get an annoying "insert disk again" message.
•When the original editor for a kind cannot be found and there is another editor on the users system that can edit that kind, Binding puts up an appropriate dlg warning the user that editor substitution has occurred. Unfortunately, if the OpenDoc document the user is dragging to is not in the foreground, the warning dlg will come up in the background. At this point, the users machine is effectively hung. (The dialog manager has control, but the dialog is not accepting events). Clicking on OK or hitting return or enter are all ignored but the default button (which may be visible). Because the dlg is in the background, the dlg may be completely obscured by other windows. Furthermore, the even if the dlg is visible it will likely be blank because the dlg never receives an update event.
OpenDoc Editor Setup
•Can't launch DAs/Apps from Apple menu when EditorSetup is forefront.
OpenDoc Imaging
•ODShape::IsSameAs returns false for two polygons with same points in clockwise order but different starting point. The shapes are formed with ODShape::SetPolygon(ODPolygon). ODPolygon::Operator== returns true for these polygons.
•If QuickDraw GX is installed, the following comparison returns false:
ODPolygon myPoly = a reasonable polygon; // simple, convex, clockwise, etc.
ODShape shape1, shape2 = new, initialized shapes;
shape1->SetPolygon(ev, &myPoly);
shape2->SetPolygon(ev, &myPoly);
shape1->IsSameAs(shape2);
The shapes appear to be valid and when rendered on the screen they cover the same area. They should test as equal. When GX
is not installed they do test as equal. If instead you use
shape1->SetPolygon(ev, &myPoly);
shape2->CopyFrom(ev, shape1);
shape1->IsSameAs(shape2);
then IsSameAs correctly returns true.
•If you install the debugging version of GX you'll get warning messages during certain clipping operations. The warning messages you get are "ClearBlockBusy: not busy" and "block busy when disposed".
•ODTransform::Invert throws for very small scaling matrices. Scalings as small as 1/32767 ought to be invertable.
•OpenDoc Poly2Rgn problem Poly2Rgn uses the port of the FrontWindow to do its region conversion, if there is a FrontWindow. Else it creates a temporary port.
OpenDoc Launcher
•If an error occurs in a nondebug build while attempting to create stationery, a file will be generated in the Finder after the process shuts down. If you double-click on this file, OpenDoc will launch and give an infinite series of error dlgs stating a program error has occured.
•Currently, the launcher checks to see if CFM is installed, and if not it reports error fragMgrInitErr. This is incorrect. The launcher needs to report an OpenDoc specific error saying CFM is unavailable.
•When more than five libraries are dropped on the launcher, it appears to run out of memory attempting to create the stationery files. It puts up rather confusing out of memory error dialogs for both the launcher and the process where the actual stationery is being constructed. One dialog appears to present a sentence fragment rather than a complete sentence. The sixth piece of stationery is only partially constructed, and an invalid stationery file corresponding to the sixth library appears to be left in the stationery folder.
• OpenDoc puts installation files into the 'Recent Applications' and 'Recent Documents' folders within the Applemenu folder.
•Error strings in OpenDoc launcher are US-centric and hard to localize.
OpenDoc Layout
•ODDrawBorder has two problems:
- It changes the grafport origin and clip and does not restore them. This is a problem during scrolling because ODDrawBorder is called by ChangeInternalTransform.
- ODDrawBorder draws the active border during scrolling even if there is nothing to redraw (because scrolling usually uses ScrollRect, part of a facet does not have to be invalidate).
•Suppose you have part A and B. If you swap from A to B and part B throws in DisplayFrameConnected OpenDoc will become unstable. At that point there will be no window open. If you try to bring up the drafts dialog you will crash.
•OpenDoc crashes if a part is swapped while a child window is open, if the child window is closed by the source frame's part.
•The implementation of ContentUpdated in Frame.cpp walks the frame hierarchy to notify containing parts, but stops when it reaches the first root frame of a window. If the window is not the root document window, it should find the source frame and continue walking the hierarchy from there.
Impact: If a source link surrounds an embedded frame, and the embedded frame is opened into its own window, changes made in the other window won't cause the link to be updated.
OpenDoc Linking
• When a user cuts content which contains a link source, and saves the document, there is simply no way to recover the link short of creating new a new one and manually recreating all of it's destinations in the present and other documents.
•ODLinkSource initializes a link's update ID to a valid update ID. However, ODLink::RegisterDependent assumes that if the update ID isn't kODUnknownUpdate, it should notify the registering part immediately. If the link is being created, this will cause the destination to be notified before the first content is available. A call to ODLink::GetContentStorageUnit will return a kODErrNoLinkContent exception.
This is only a problem for cross-document links because ordinarily the source part will have already updated the link before returning the link object. In the case of a cross-document link, however, the edition file will have been written but an event will be queued for the destination document to read it. If parts handle the failure of GetContentStorageUnit correctly, they will soon receive a second notification as soon as the destination process accepts the Apple event to read the edition file and update the link.
•Recent changes to the Save model allow the user to specify the location of the document when first saved. This can cause the Edition files can now become separated from their source documents, which is undesirable.
•The Paste As dialog cannot interact with user if dropped in background window. The workaround is that the user can use copy and Paste As, or cut and pasteAs, or more generally, can make the selection, then activate the target process before initiating the command-drag action.
•Cannot complete manual link sequence using cmd A to select all.
•Suppose a draft contains two parts that each maintain a destination of the same link, both of which update automatically. Suppose one part has been internalized, but the other has not (perhaps its on page 50). If the link is updated, one part will be notified and can update its content. If the two parts are copied (along with other stuff, say) and pasted in another document, the link will be removed and the parts will contain just content. However, each will contain content from a different change to the link, even though both were automatically updated destinations of the same link.
•Create a cross-document link. Set the destination to update manually. Close and save the source document. Discard the edition file and empty the trash. Open the source document. Activate the destination document, and show Link Info on the destination.
Note that the "Update Now" button is enabled, even though no new content is available.
Two possible solutions: First, examine the mod date of the edition file; if its the same as the current change time of the link source, don't update the link. Alternatively, use the new technique for re-writing a link to update the link source without notifying destinations. Since fulfillment of promises are forced when the link is written to an edition file in the source document, and assuming an edition file isn't written more than once a second, the first approach can probably be used.
OpenDoc Scripting
•OpenDoc cannot find frameless parts by id or name. Some parts, like services, can exist without frames. OpenDoc should be able to allow for scripting of these parts. Currently thought, the default semantic interface doesn't search for frameless parts.
•Potential clash with default accessor tokens and a part's token. The default accessors use cProperty as a descriptorType for tokens that they create. However, a part may also use this descriptorType for its own tokens. A part will be called to dispose any token that was created in its context, including those created by the default accessors. However, a part using cProperty tokens
will think that one of the default accessor tokens is one of its own and try to dispose it.
Workaround: Parts shouldn't be using lowercase descriptor types.
•Setting values using in-document data fails.
•Query about whether part does "whose" can go to the wrong part. Parts are asked whether they want to do whose clause resolution. Obviously, they are asked before the resolution is started. However, sometimes the resolution is started in the context of one part, will another will finish the resolution because the first part swaps. The two parts might have different ideas about how they want to handle the resolution.
OpenDoc Shell
•A side effect of converting the existing document to stationery, is that it is not redrawn in the finder until the finder is forced to redraw the window, so it looks like it's not stationery, but in fact it is.
•Open Document option in DOCUMENT menu will not open a TeachText file - on some machines only (and we're not sure which ones they are yet).
•Document New does not save properly on a floppy disk - occasionally. We can't reproduce this one 100% of the time but it does show up from time to time.
•When swapping to an editor that could not be loaded, OpenDoc reports "Could not find all necessary shared libraries. Try re-installing OpenDoc". Re-installing is NOT necessary, nor would it likely help, since the problem is with the Editor not with the OpenDoc installation.
•In an OpenDoc document, choose Drafts from the Document menu. Press the Create Draft button. Notice that even though the Drafts dialog isn't the front window, its controls still appear enabled. This confuses the user about which controls are available.
•The Shell does not properly recover from any error encountered between when it shuts a document down prior to moving it and when it opens it up again. It *should* reopen it from the original location on failing to move it, with appropriate warnings to the user of course, but instead it just goes into a document-less state.
• Document Info Name field needs a filter proc. Currently, the user can type in a document name that contains a colon ":". The colon , of course, is not allowed in a valid MacOS user filename. We don't currently warn the user, or tell them why they can't do this -- we just ignore their entry , refusing to change the documents name.
•Part editors dropped on the System Folder end up in wrong folder.
•Changing document size doesn't cause Save to be enabled.
•Clicking "Don't Save" when closing a new document of the same name as a document in the trash fails (if the file in the trash is locked).
OpenDoc Storage
•When opening a document and accessing a draft from that document using read-only access, you can't open that same document again (for read-only access) because the file system has opened it for read-write access.
Workaround is to Finder lock the file before opening it (which can be done programmatically).
•When attempting to open some large files with many embedded objects, you can get a crash in CMDraftPurge. The problem is that it gets an object pointer from an iterator but doesn't check it for nil before dereferencing it. This leads to a Memory Access Exception (this occurs in low memory primarily).
•ODDraft::AcquirePersistentObject() crashes if passed in non-persistent frame.
•Parts dragged to Finder are modified if opened (Save becomes enabled even if no changes have been made).
UI Events
•Calling ODSession::RegisterIdle() at idle time brings up a "Program Error" alert.
•When a dispatch module is installed into the dispatcher using AddMonitor and never removed (i.e. by a Shell Plugin), they do not get deleted when the document is closed.
Workaround is to create an object namespace and install the dispatch module into the object namespace so that it will be deleted when the namespace is deleted by the namespace manager.
•OpenDoc will let the user switch to another process while a document is coming up, which leads to the window being drawn as an active window, even though it is in the background.
•Parts cannot attach help balloons to their menu items since their resource forks are not active at the time MenuSelect is called.
Workaround:
A part editor could call BeginUsingLibraryResources when it acquired the menu focus, and EndUsingLibraryResources when it lost the focus. This workaround has not been tried so...
•Documentation states that the undo and redo strings are ignored by AddActionToHistory in a mutli-stage transaction until kODEndAction is passed. However, if the caller chooses to avoid the overhead of creating strings that will be ignored by passing in kODNull string ptrs, an exception will be thrown in some string processing code. The code in question should probably not even
be called unless it's either a single action, or the end action of a multiple staged transaction, since the strings are supposed to be ignored otherwise.
Workaround: Pass in a pointer to an empty string, or use some other arbitrary string that's kicking around.
•When a multi-step operation is aborted, the AbortCurrentTransaction method of the undo object must undo all actions already performed in the current transaction. In the current implementation, AbortCurrentTransaction just disposes these actions, committing them in the "done" state. This leaves the operation in a partially-completed state, which cannot be undone. The only
way to completely restore the state of the document is to revert the document or close without saving changes.
•Because hidden floating windows are sent to the back, creating a new floating window with a hidden floating window creates it in front of the frontmost floating window which is behind all of the other windows.
•Open a Read-only document which has embedded parts. Select one of the embedded parts and choose "Open" from the Document menu. Save A Copy of the document. Open the copy of the document, notice that the new window which was opened is not open, this is incorrect: the copy should look exactly like what the document looked like immediately before the Save A Copy command was confirmed.
Workaround is to open the document readwrite, and then open a new window and Save A Copy. The new window is open in the copy.
OpenDoc Utilities
•PlatformFile::Specify does not reset the scripttag, refnum, and file parms.
Workaround: Don't use the specify call. Just destroy and new platform files each time need to work with a different file.
•ODGetPartName crashes if it is called on a root frame before the window belonging to the root frame is registered. Actually, the culprit is ODGetFileIfRoot, which will call AcquireWindow and then use the result (without checking it) if there is not containing frame.
Workaround: Call ODGetPartName and change the name of the window after it is created and registered but before it is shown (since windows in OpenDoc need to be created invisible, anyway).
•TempObj.cpp now has a hardcoded dependency on PlfmFile.cpp.
